This invention relates in general to streaming media and more specifically to streaming media using the HTTP protocol.
In data communications it is typically desirable to retrieve data as quickly as possible. This is not the case, however, for data which may be rendered over time (e.g. audio or video). The Hypertext Transfer Protocol (HTTP) is a popular Internet data retrieval protocol. In general HTTP requests are serviced as quickly as possible and HTTP does not take into account the possibility of rendering over time. The Real Time Streaming Protocol (RTSP), on the other hand, was designed to deliver data which may be rendered over time, in a just in time manner. RTSP is more complex, more computationally expensive, and less well supported than HTTP. Consequently, many still rely on HTTP for delivering audio and video content. The download as fast as possible paradigm, however, uses more bandwidth than is necessary, and requires that clients have buffer space to store the data, and encourages servers to use all available resources to send the data as quickly as possible. This is taxing for clients with limited resources (e.g. mobile devices). This also inhibits network and server scalability.
US Patent Application Publication 2008/0114889A1 by Deshpande describes a method for pacing from an existing web server, by calculating a strict pacing schedule, based on the target bit rate and the offset from the beginning of the file. Deshpande also allows for client specified segment sizes and target bit rates. The implied architecture, however, does not specifically address server scalability issues, client intelligence, or rendering optimizations.
Other known mechanisms include those described in RFC 3448, “TCP Friendly Rate Control (TFRC)”, and in a paper by Wei et al. entitled “TCP Pacing Revisited”.